home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9632 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.9 KB  |  66 lines
  1. Newsgroups: comp.arch.arithmetic,comp.lang.c,comp.lang.c++,comp.lang.misc
  2. Path: news.clark.net!bms88!stuart
  3. From: stuart@bmsi.com (Stuart D. Gathman)
  4. Subject: Re: Languages and architecture  Was: Re: Access carry flag from C
  5. Organization: Business Management Systems, Inc., Fairfax, VA
  6. Date: Fri, 1 Mar 1996 20:29:04 GMT
  7. Message-ID: <1996Mar1.202904.20064@bmsi.com>
  8. References: <Dn1C9z.DGv.0.net@indra.com> <3132f352.32867731@netline-fddi.jpl.nasa.gov> <4h1mcb$178u@b.stat.purdue.edu>
  9.  
  10. In article <4h1mcb$178u@b.stat.purdue.edu> hrubin@b.stat.purdue.edu (Herman Rubin) writes:
  11. >In article <3132f352.32867731@netline-fddi.jpl.nasa.gov>,
  12. >Kevin Quitt <kdq@emoryi.jpl.nasa.gov> wrote:
  13. >>On Mon, 19 Feb 1996 18:20:22 GMT, sullivan@indra.com (Steve Sullivan) wrote:
  14. >
  15. >>>Is it possible to determine if a fixed point overflow has
  16. >>>occurred from within C?
  17. >
  18. >>No, it's not, because as far as C is concerned, there doesn't have to be a
  19. >>carry bit.  Once overflow has occurred, you're into undefined behaviour.
  20. >
  21. >This is a problem with C and just about every other language, which 
  22. >impacts adversely the architecture of machines.
  23. >
  24. >The language designers typically remove much of what a knowledgeable
  25. >user will want to use from the language, because their own knowledge
  26. >is lacking in that area.  Then the designers of the arithmetic units
  27. >of the machines drop that property, because the languages do not 
  28. >have it.  
  29. >
  30. >And now we have computers on which many cheap instructions and 
  31. >properties are not present.  We cannot detect overflow, so we
  32. >are forced to either use many times the number of instructions,
  33. >or find some other clumsy way areound the problem.  We cannot
  34. >do decent precise fixed point arithmetic, so the time for 
  35. >multiple precision arithmetic, fixed or floating, is increased
  36. >by a substantial factor.  Even the floating point unit has been
  37. >restricted so that, for example, doubling the machine precision
  38. >is a major undertaking.
  39. >
  40. >We can always simulate any computer on any other.  Hardware 
  41. >deficiencies are not handled efficiently by software.
  42.  
  43. I program in C for Wintel, 68k, 88k, and PowerPC.  The latter three
  44. (and I believe the former) all have cheap hardware overflow detection.
  45. While the C standard does not address this, it is easy to access via
  46. inline assembler in the GNU C and Borland compilers.  As an example
  47. for all you Wintel fans out there (the largest audience for those
  48. 4 processors), I use a swap() function a lot (to convert to a reasonable
  49. byte order :-):
  50.  
  51. #define swap(x) (_AX = (x),__emit__(0x86,0xe0),(short)_AX)
  52.  
  53. generates an optimal xchg instruction.  If you want to handle nested
  54. expressions involving swap(), then a more general version is
  55.  
  56. inline short swap(short x) {
  57.   _ax = x;
  58.   asm xchg ah,al
  59.   return _ax;
  60. }
  61. -- 
  62. Stuart D. Gathman    <stuart@bmsi.com> / <..!uunet!bms88!stuart>
  63.                 Business Management Systems Inc.
  64.                Phone: 703 591-0911 Fax: 703 591-6154
  65.           "Microsoft is the QWERTY of Operating Systems" - SDG
  66.